Data stream format conversion method and recording method for the same

ABSTRACT

A method for converting a data stream in a first format into a data stream in a second format is provided. Each stream includes data packs in which video/audio data are stored and a control pack for use in a playback control of the stream. In the first format stream, address information, representing addresses of the data packs and not required while the stream is played back, is present and associated with the stream. In the second format stream, address information, representing addresses of the data packs and required while the stream is played back, is stored in the control pack. The method includes the steps of: acquiring the first format stream and its associated address information; generating a second control pack in the second format from a first control pack in the first format, the second control pack storing the address information acquired; and replacing the first control pack with the second control pack, thereby generating the second format stream from the first format stream.

TECHNICAL FIELD

The present invention relates to the technology of converting the formatof a content including video and audio. More particularly, the presentinvention relates to the technique of converting a content, which wasrecorded so as to comply with the DVD Video Recording standard, forexample, into a content complying with the DVD Video standard.

BACKGROUND ART

In recent years, various standards for recording a content on a storagemedium such as an optical disk have been defined. As for DVDs, forexample, the DVD Video standard (which will be referred to herein as“Video standard”) is defined as a recording format for a package mediumto store a read-only content such as a movie thereon. Also, the DVDVideo Recording standard (which will be referred to herein as “VRstandard”) is defined as a recording format for recording a content inreal time and for making it editable afterward. A general read-only DVDplayer can play back a content that was recorded so as to comply theVideo standard but cannot play back a content that was recorded so as tocomply with the VR standard.

Currently, read-only DVD players are still far more popular than anyother type of DVD player/recorder. Accordingly, there is a lot of needto convert a content that was recorded so as to comply with the VRstandard into a content compliant with the Video standard. For example,if video and audio, which were recorded on a storage medium with acamcorder so as to comply with the VR standard, should be handed to someacquaintance that owns a read-only player, the video and audio recordedneeds to be converted into a content compliant with the Video standard.

In the prior art, such a format conversion process is carried out bydecoding once a content that was recorded so as to comply with the VRstandard, converting the content into a digital baseband signal, andthen encoding the signal again such that the signal complies with theVideo standard.

Alternatively, as in the process disclosed in Japanese PatentApplication Laid-Open Publication No. 2002-150713, the format conversionprocess may also be carried out by recording in advance the physicalstorage locations of respective data of a given content on a storagemedium and the time stamps thereof and by making reference to thesepieces of information.

However, in the conventional format conversion process in which acontent is once decoded and then re-encoded, the intervening re-encodingprocess step requires the same amount of time to get the conversion doneas the amount of time it takes to record the original content. Inaddition, the image quality of the content easily deteriorates, which isa problem.

Also, in the format conversion process to perform by reference to thepre-recorded physical storage locations and time stamps of the data, thephysical storage locations need to be recalculated during the formatconversion, thus requiring a relatively long conversion time, too.

DISCLOSURE OF INVENTION

An object of the present invention is to convert the format of a givencontent in a short time without deteriorating the image quality thereof.

A data stream conversion method according to the present invention canbe used to convert a data stream in a first format into a data stream ina second format. Each data stream includes data packs in which videodata and audio data are stored and a control pack for use in a playbackcontrol of the data stream. In the data stream in the first format,address information, which represents the addresses of the data packsand which is not required while the data stream is played back, ispresent and associated with the data stream. In the data stream in thesecond format, address information, which represents the addresses ofthe data packs and which is required while the data stream is playedback, is stored in the control pack. The conversion method includes thesteps of: acquiring the data stream in the first format and theassociated address information thereof; generating a second control packin the second format from a first control pack in the first format, thesecond control pack storing the address information acquired; andreplacing the first control pack with the second control pack, therebygenerating the data stream in the second format from the data stream inthe first format.

The data stream in the first format may be an arrangement of multipledata units, each of the data units including a plurality of data packsand the first control pack. The method may further include the steps of:locating an extension field, which is included only in the first one ofthe data packs, in each of the second and following data units; andreplacing data of the located extension field with predeterminedstuffing data.

The method may further include the steps of: detecting a data length ofa stuffing field, which is arranged after the extension field and inwhich the stuffing data is stored in advance; and determining whether ornot the data length detected is a reference length or less. The step ofreplacing may be carried out if the data length is the reference lengthor less.

The data stream in the first format may be an arrangement of multipledata units, each of the data units including a plurality of data packsand the first control pack. Each data pack may include at least onepacket in which either the video data or the audio data is stored. Themethod may further include the steps of: locating an extension field,which is included only in the first one of the data packs, in each ofthe second and following data units; detecting a data length of astuffing field, which is arranged after the extension field and in whichstuffing data is stored in advance; determining whether or not the datalength detected is a reference length or less; deleting the extensionfield and the stuffing field if the data length is greater than thereference length; and adding a padding packet, of which a packet lengthcorresponds to a combined field length of the extension and stuffingfields deleted, to the at least one packet.

The data stream in the first format may be an arrangement of multipledata units, each of the data units including a plurality of data packsand the first control pack. Each data pack may include a packet in whicheither the video data or the audio data is stored and a padding packetfor adjusting a pack length of the data pack. The method may furtherinclude the steps of: locating an extension field, which is includedonly in the first one of the data packs, in each of the second andfollowing data units; deleting the extension field; and adjusting thepacket length of the padding packet according to the field length of theextension field deleted.

The address information may be stored in the first control pack of thedata stream in the first format, and the step of acquiring the addressinformation may include extracting the address information stored in thefirst control pack.

The step of acquiring the address information may include extracting theaddress information stored in an attribute information field, on whichan arbitrary type of information is describable, within the firstcontrol pack.

The step of acquiring the address information may include extracting theaddress information stored in a data file separately from the datastream.

The address information may show a storage location of a data pack inwhich a picture representing the video is stored and a storage locationof another data pack in which audio to be reproduced synchronously withthe picture is stored.

The first data pack may be the first one of video packs including videodata or that of audio packs including audio data.

A format conversion apparatus according to the present invention is usedto convert a data stream in a first format into a data stream in asecond format. Each data stream includes data packs in which video dataand audio data are stored and a control pack for use in a playbackcontrol of the data stream. In the data stream in the first format,address information, which represents the addresses of the data packsand which is not required while the data stream is played back, ispresent and associated with the data stream. In the data stream in thesecond format, address information, which represents the addresses ofthe data packs and which is required while the data stream is playedback, is stored in the control pack. The format conversion apparatusincludes: a receiving section for acquiring the data stream in the firstformat and the associated address information thereof; and a packgenerating section for generating a second control pack in the secondformat from a first control pack in the first format, the second controlpack storing the address information acquired. The pack generatingsection replaces the first control pack with the second control pack,thereby generating the data stream in the second format from the datastream in the first format.

The data stream in the first format may be an arrangement of multipledata units, each of the data units including a plurality of data packsand the first control pack. The format conversion apparatus may furtherinclude: a decision section for locating an extension field, which isincluded only in the first one of the data packs, in each of the secondand following data units; and a converting section for replacing data ofthe located extension field with predetermined stuffing data.

The decision section may detect a data length of a stuffing field, whichis arranged after the extension field and in which the stuffing data isstored in advance, and may determine whether or not the data lengthdetected is a reference length or less. If the data length is thereference length or less, the converting section may replace the datawith the stuffing data.

The data stream in the first format may be an arrangement of multipledata units, each of the data units including a plurality of data packsand the first control pack. Each data pack may include at least onepacket in which either the video data or the audio data is stored. Theformat conversion apparatus may further include: a decision section forlocating an extension field, which is included only in the first one ofthe data packs, in each of the second and following data units,detecting a data length of a stuffing field, which is arranged after theextension field and in which stuffing data is stored in advance, anddetermining whether or not the data length detected is a referencelength or less; a packet generating section for generating a paddingpacket; and a converting section for deleting the extension field andthe stuffing field if the data length is greater than the referencelength, adjusting the packet length of the padding packet according tothe combined field length of the extension and stuffing fields deleted,and then adding the padding packet to the at least one packet.

The data stream in the first format may be an arrangement of multipledata units, each of the data units including a plurality of data packsand the first control pack. Each data pack may include a packet in whicheither the video data or the audio data is stored and a padding packetfor adjusting a pack length of the data pack. The format conversionapparatus may further include: a decision section for locating anextension field, which is included only in the first one of the datapacks, in each of the second and following data units; and a convertingsection for deleting the extension field and adjusting a packet lengthof the padding packet according to the field length of the extensionfield deleted.

The address information may be stored in the first control pack of thedata stream in the first format, and the pack generating section mayextract the address information stored in the first control pack.

The pack generating section may extract the address information storedin an attribute information field, on which an arbitrary type ofinformation is describable, within the first control pack.

The pack generating section may extract the address information storedin a data file separately from the data stream.

The address information may show a storage location of a data pack inwhich a picture representing the video is stored and a storage locationof another data pack in which audio to be reproduced synchronously withthe picture is stored.

The first data pack may be the first one of video packs including videodata or that of audio packs including audio data.

A data stream conversion program according to the present Invention,which is executable by a computer, is used to convert a data stream in afirst format into a data stream in a second format. Each data streamincludes data packs in which video data and audio data are stored and acontrol pack for use in a playback control of the data stream. In thedata stream in the first format, address information, which representsthe addresses of the data packs and which is not required while the datastream is played back, is present and associated with the data stream.In the data stream in the second format, address information, whichrepresents the addresses of the data packs and which is required whilethe data stream is played back, is stored in the control pack.Conversion processing to be carried out by the computer following theprogram includes the steps of: acquiring the data stream in the firstformat and the associated address information thereof; generating asecond control pack in the second format from a first control pack inthe first format, the second control pack storing the addressinformation acquired; and replacing the first control pack with thesecond control pack, thereby generating the data stream in the secondformat from the data stream in the first format.

A recording method according to the present invention is used to recorda data stream in a first format. The recording method includes the stepsof: receiving data of a content representing video and audio; generatinga data pack, in which data of the video is stored, and a data pack, inwhich data of the audio is stored, based on the data received; acquiringaddress information that represents the addresses of the data packsarranged; generating a control pack in accordance with controlinformation, which is required for controlling playback of the datapacks; arranging the data packs and the control pack in the firstformat, thereby generating the data stream; acquiring addressinformation that shows a storage locations of the data packs in the datastream; and recording the address information and the data stream on astorage medium in association with each other.

The recording method may further include the step of storing the addressinformation in the control pack.

The recording method may further include the step of storing the addressinformation in a data file separately from the data stream.

The address information may show a storage location of a data pack inwhich a picture representing the video is stored and a storage locationof another data pack in which audio to be reproduced synchronously withthe picture is stored.

On a storage medium processed by the recording method, the addressinformation is stored in an attribute information field, on which anarbitrary type of information is describable, within the control pack inthe data stream. Alternatively, the storage medium may store the addressinformation in a data file separately from the data stream.

A recorder according to the present invention can record a data streamin a first format on a storage medium. The recorder includes: anencoder, which receives data of a content representing video and audio,generates a data pack, in which data of the video is stored, and a datapack, in which data of the audio is stored, based on the data receivedand outputs address information that represents the addresses of thedata packs arranged; a generating section for generating a control packin accordance with control information, which is required forcontrolling playback of the data packs; a system encoder for arrangingthe data packs and the control pack in the first format, therebygenerating the data stream; and a writing section for writing at leastthe data stream on a storage medium.

The generating section may acquire and describe the address informationin the control pack. Alternatively, the writing section may also storethe address information in a data file separately from the data stream.

A recording program according to the present invention, which isexecutable by a computer, is used to generate and record a data streamin a first format. Recording processing to be carried out by thecomputer following the program includes the steps of: receiving data ofa content representing video and audio; generating a data pack, in whichdata of the video is stored, and a data pack, in which data of the audiois stored, based on the data received; acquiring address informationthat represents the addresses of the data packs arranged; generating acontrol pack in accordance with control information, which is requiredfor controlling playback of the data packs; arranging the data packs andthe control pack in the first format, thereby generating the datastream; acquiring address information that shows a storage locations ofthe data packs in the data stream; and recording the address informationand the data stream on a storage medium in association with each other.

A data stream conversion method according to the present invention canbe used to convert a data stream in a first format into a data stream ina second format. Each data stream includes data packs in which videodata and audio data are stored and a control pack for use in a playbackcontrol of the data stream. In the data stream in the first format,address information, which represents the addresses of the data packsand which is not required while the data stream is played back, ispresent and associated with the data stream. In the data stream in thesecond format, address information, which represents the addresses ofthe data packs and which is required while the data stream is playedback, is stored in the control pack. The conversion method includes thesteps of: analyzing the data stream in the first format; finding thearrangement of a first control pack and the data packs in the datastream, thereby acquiring the address information of a predetermineddata pack; generating a second control pack in the second format fromthe first control pack in the first format, the second control packstoring the address information acquired; and replacing the firstcontrol pack with the second control pack, thereby generating the datastream in the second format from the data stream in the first format.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1(a) shows a data structure for an MPEG2 program stream 10 acompliant with the VR standard.

FIG. 1(b) shows a data structure for an MPEG2 program stream 10 bcompliant with the Video standard.

FIG. 2 shows the data structure of an RDI pack 11 a.

FIG. 3(a) shows the data structure of a navigation pack 11 b.

FIG. 3(b) shows the data structure of data search information 30.

FIG. 3(c) shows the data structure of general information 31.

FIG. 3(d) shows the data structure of sync information 32.

FIG. 4 shows the data structure of the video pack 40.

FIG. 5 shows a correlation between the VR-compliant stream 10 a andVideo-compliant stream 10 b in format conversion processing according tothe present invention.

FIG. 6 shows the arrangement of functional blocks in a data processor 60according to a preferred embodiment of the present invention.

FIG. 7 shows a schematic data structure of an RDI pack 50.

FIG. 8 is a flowchart showing the procedure of processing done by anencoder 61.

FIG. 9(a) shows how to perform a conversion process into stuffing bytes.

FIG. 9(b) shows how to perform a conversion process into a paddingpacket.

FIG. 9(c) shows how to perform an integration process into a paddingpacket.

FIG. 10 is a flowchart showing a procedure of the format conversion.

FIG. 11 is a flowchart showing another procedure of the formatconversion.

FIG. 12 shows the arrangement of functional blocks in a data processor160 according to another preferred embodiment of the present invention.

BEST MODE FOR CARRYING OUT THE INVENTION

Hereinafter, content format conversion processing and its relatedtechniques according to the present invention will be described.

As used herein, the “content” refers to a piece of information includingvideo and/or audio. That is to say, the “content” includes videoinformation representing video and/or audio information representingaudio. The content may be moving pictures taken with a camcorder or ananalog broadcast, for example.

In this description, the format yet to be subjected to the conversion issupposed to be compliant with the DVD Video Recording standard (the VRstandard) and the format subjected to the conversion is supposed to becompliant with the DVD Video standard (the Video standard).

Hereinafter, the data structures of two data streams compliant with theVR standard and the Video standard, respectively, will be describedfirst, and then various preferred embodiments of the format conversionprocessing will be described.

FIG. 1(a) shows a data structure for an MPEG2 program stream 10 acompliant with the VR standard (which will be referred to herein as a“VR-compliant stream 10 a”).

The VR-compliant stream 10 a includes a plurality of video objects(VOBs) #1, #2, . . . , and #k. Supposing the VR-compliant stream 10 a isa content that was taken with a camcorder, for example, each VOB storesmoving picture data that was generated during a single video recordingsession (i.e., since the user started recording the video and until heor she stopped doing it).

Each VOB includes a plurality of VOB units (video object units; VOBUs)#1, #2, . . . , and #n. Each VOBU is a data unit containing data in anamount corresponding to a video playback duration of about 0.4 second toabout 1 second. Hereinafter, the data structure of VOBUs will bedescribed with the first and second VOBUs taken as an example.

VOBU #1 is composed of a number of packs. In the VR-compliant stream 10a, each pack has a fixed data length (also called a “pack length”) of 2kilobytes (i.e., 2,048 bytes). At the top of the VOBU, a real timeinformation pack (RDI pack) 11 a is positioned as indicated by “R” inFIG. 1(a). The RDI pack 11 a is followed by multiple video packs “V”(including a video pack 12 a) and multiple audio packs “A” (including anaudio pack 13 a). It should be noted that if the video data has avariable bit rate, the data size of each VOBU is changeable within arange defined by a maximum read/write rate. However, if the video datahas a fixed bit rate, the data size of each VOBU is substantiallyconstant.

Each pack stores the following information. Specifically, the RDI pack11 a stores various information for controlling the playback of theVR-compliant stream 10 a, e.g., information representing the playbacktiming of the VOBU and information for controlling copying of theVR-compliant stream 10 a. The video packs 12 a store MPEG2-compressedvideo data thereon. The audio packs 13 a store audio data that wascompressed so as to comply with the MPEG2 Audio standard, for example.In adjacent video and audio packs 12 a and 13 a, video and audio data tobe played back synchronously with each other may be stored. However,their arrangement (order) may be arbitrarily determined. TheVR-compliant stream 10 a is supposed herein to include no extensionstreams. The detailed data structures of the RDI pack 11 a and videopacks 12 a will be described later with reference to FIGS. 2 and 4.

VOBU #2 is also made up of a plurality of packs. An RDI pack 14 a islocated at the top of VOBU #2, and then followed by a plurality of videopacks 15 a and a plurality of audio packs 16 a. The contents of theinformation to be stored in these packs are similar to those of VOBU #1.

FIG. 1(b) shows a data structure for an MPEG2 program stream 10 bcompliant with the Video standard (which will be referred to herein as a“Video-compliant stream 10 b”).

The data structure of the Video-compliant stream 10 b is similar to thatof the VR-compliant stream 10 a. Specifically, the Video-compliantstream 10 b also includes a plurality of VOBs #1, #2, . . . , and #k,each of which consists of a plurality of VOBUs. And each VOBU includesvideo packs 12 b, 15 b, etc. and audio packs 13 b, 16 b, etc. The videopacks store video data thereon and the audio packs store audio datathereon.

The differences in data structure between the Video-compliant stream 10b and the VR-compliant stream 10 a are as follows. Specifically, in theVideo-compliant stream 10 b, not the RDI pack of the VR-compliant stream10 a but a navigation pack 11 b, 14 b, etc. as identified by “N” islocated at the top of each VOBU. The navigation pack stores navigationinformation (to be described later) for controlling the playback of thevideo data and audio data.

In addition, in the Video-compliant stream 10 b, the video pack 12 b andthe audio pack 13 b, which appear first in VOBU #1 of each VOB, have aunique field (i.e., a PES extension field to be described later), whichis not included anywhere else within the same VOBU or in any other videopack or audio pack within the same VOB. More specifically, such a fieldis present in the video pack 12 b but absent from the video pack 15 b.And such a field is present in the audio pack 13 b but absent from theaudio pack 16 b.

To convert the format of the VR-compliant stream 10 a into that of theVideo-compliant stream 10 b, those differences in data structure need tobe taken into consideration. That is why the data structure of the RDIpack of the VR-compliant stream 10 a and that of the navigation pack ofthe Video-compliant stream 10 b will be described with reference to FIG.2 and FIGS. 3(a) through 3(d). And then the data structure of the videopacks will be described with reference to FIG. 4.

FIG. 2 shows the data structure of the RDI pack 11 a. The RDI pack 11 aincludes a pack header (Pack_H) showing the type of the pack, a systemheader (system_H) and an RDI packet, which are arranged in this order tomake up a pack of 2,048 bytes. The RDI packet includes a packet header(Packet_H) showing the type of the packet, an ID field and a data field.In the data field, a field (RDI_GI) to store RDI information showing theplayback timing of the VOBU, a field (DCI_CCI) to store information forcontrolling copying of the VR-compliant stream 10 a, and amanufacturer's information field describing arbitrary attributeinformation are defined. An apparatus for generating the VR-compliantstream 10 a may describe its maker (manufacturer) defined arbitraryinformation as the attribute information.

FIG. 3(a) shows the data structure of the navigation pack 11 b. Thenavigation pack 11 b includes a pack header (Pack_H) showing the type ofthe pack, a system header (system_H) and a PCI packet and a DSI packeton which playback control information is stored. These headers andpackets are also arranged in this order to make up a pack of 2,048bytes.

Among various data that make up the navigation pack 11 b, the datastructure of the DSI packet will be described in detail below. The DSIpacket forms the second half of the navigation pack 11 b, which startsat a location of 1,025 bytes as counted from the top of the navigationpack 11 b, and has a data length of 1,024 bytes. In the last field ofthe DSI packet, which starts at a location of 8 bytes as counted fromthe top, data search information 30 is stored.

FIG. 3(b) shows the data structure of the data search information 30.The data search information 30 is a collection of various types ofinformation including navigation information for controlling theplayback of video data and audio data. Among those types of information,general information (DSI_GI) 31 about the navigation information andsync information (SYNCI) 32 will be described. The general information31 is arranged at the top of the data search information 30 and has adata length of 32 bytes.

FIG. 3(c) shows the data structure of the general information 31. Thegeneral information 31 includes address information VOBU_(—)1STREF_EA 33a, VOBU_(—)2NDREF_EA 33 b and VOBU_(—)3RDREF_EA 33 c showing therespective addresses of first, second and third video referencepictures. The navigation information described above includes thesepieces of address information. The first address information 33 a startsat a location of 13 bytes as counted from the top of the generalinformation 31. Each of these pieces of address information 33 a, 33 band 33 c has a data length of 4 bytes.

The address information is a piece of information indicating thelocation of a video pack in which the last portion of data,corresponding to its associated reference picture, is stored. Morespecifically, the “location of a video pack” is represented by a valueshowing the pack number of that pack as counted from the top of theVOBU. As described above, each pack has a pack length of 2,048 bytes.Thus, the top location of that pack is represented by (value of theaddress information)×2,048 bytes. Also, the “reference picture” refersto an intra picture encoded with a frame structure, a forward predictedpicture encoded with the frame structure, a pair of intra picturesencoded with a field structure, a pair of forward predicted picturesencoded with the field structure, or an intra picture encoded with thefield structure and then immediately followed by a forward predictedpicture. The reference picture is arbitrarily determined by the playbackduration, for example.

FIG. 3(d) shows the data structure of the sync information 32. The syncinformation 32 includes audio pack address information (A_SYNCA) 34. Thenavigation information described above includes this addressinformation, too. The address information is a piece of informationshowing the location of an audio pack in which audio data to be playedback synchronously with its associated picture is stored. In this case,the “location of an audio pack” is represented by a value showing thepack number of that pack as counted from the top of the VOBU. The top ofthe audio pack is located as in the example of the video pack. The syncinformation 32 has a data size of 144 bytes and is stored up to alocation of 403 to 546 bytes as counted from the top of the data searchinformation 30.

The address of a single audio pack is specified by a field(A_PCK_location) 34 a and a field (A_PCKA) 34 b. The field 34 a has afield length of 1 bit, which is used to show whether its associatedaudio pack is located before or after that bit. If the audio pack islocated before that bit, then “1” is set. On the other hand, if theaudio pack is located after that bit, then “0” is set. The field 34 bhas a field length of 15 bits, which is used to describe the location ofthe audio pack. Eight pairs of fields 34 a and 34 b, each having acombined length of 2 bytes, may be provided. Thus, a field to describethe address information of the audio pack always has a field length of16 bytes (=8×2 bytes).

Next, the data structure of a video pack will be described withreference to FIG. 4. As far as the video pack is concerned, the samedata structure may be adopted in both of the VR-compliant stream 10 aand Video-compliant stream 10 b.

FIG. 4 shows the data structure of the video pack 40. The video pack 40includes a video packet 41 and a padding packet 42. The padding packet42 is provided to adjust the pack length of a data pack. Thus, nopadding packets are provided if there is no need to adjust the packlength. In that case, only the video packet 41 will be included in thevideo packet 40.

The video packet 41 includes a pack header (Pack_H) of 14 bytes, asystem header (system_H) of 24 bytes, a packet header (Packet_H) 41 aand a payload, which are arranged in this order from the top. In thepack header, information showing the type of the pack (i.e., a videopacket in this case) is described. The system header is always added tothe first pack of each VOBU. The packet header 41 a will be described indetail later. And in the payload, compressed and encoded video data isdescribed.

Meanwhile, the padding packet 42 includes a packet header (Packet_H) 42a and padding data 42 b. In the packet header 42 a, not only informationshowing the identity as a padding packet but also the data length (bytelength) of the padding packet 42 a are described. The data length isdescribed in the field of fifth and sixth bytes (PES_packet_length). Apredetermined value is stored as the padding data 42 b. This value maybe a series of meaningless values “0xFF (hexadecimal number)”. Theamount of the padding data 42 b included is determined so as to adjustthe pack length of the video pack 40 to 2,048 bytes as described above.

Next, the data structure of the packet header 41 a of the video packet41 will be described. The packet header 41 a includes a packet lengthfield 43, a flag field 44 and a header data length field 45. Dependingon the values of a time flag field 44 a and a PES extension flag field44 b, the packet header 41 a may further include an additional field 46.

In the packet length field 43, a packet length (byte length) as measuredfrom that field through the end of the video packet 41 is described.Accordingly, if there is any padding packet 42, the video packet 41 hasa shorter packet length and a smaller packet length value is describedin the packet length field 43. The next flag field 44 includes a timeflag field (PTS_DTS_flag) 44 a and a PES extension flag field(PES_extension_flag) 44 b. In the time flag field 44 a, a flag showingwhether or not there are a presentation time stamp (PTS) and a decodingtime stamp (DTS) is described as will be mentioned later. In the PESextension flag field 44 b, a flag showing whether or not there is a PESextension field is described as will be mentioned later. And in theheader data length field 45, the sum of the field lengths of theadditional field 46 and a stuffing byte field 49 is stored.

Next, the additional field 46 will be described. For example, if thetime flag field 44 a shows that there are both PTS and DTS, one of PTSand DTS fields 47, each having a length of 5 bytes, is provided as theadditional field 46. The PTS is information about the presentation timeof video data, while the DTS is information about the decoding time.Depending on the value of the time flag field 44 a, one of these twofields is provided.

Also, a PES extension field 48 may be provided as the additional field46. In the PES extension field 48, information required for decoding theprogram stream 10 a or 10 b, e.g., the capacity of a decoding databuffer, is described.

In the VR-compliant stream 10 a, the PES extension field 48 is providedfor the first video pack and the first audio pack in each VOBU. In theVideo-compliant stream 10 b on the other hand, the PES extension field48 is provided for the first video pack and the first audio pack in onlythe first VOBU of each VOB. The PES extension field 48 may be present ifthe PES extension flag field 44 b is one but absent if the PES extensionflag field 44 b is zero, for example.

The packet header 41 a sometimes includes a stuffing byte field 49. Inthe stuffing byte field 49, stuffing bytes are stored to adjust the packlength. The stuffing bytes are byte data such as meaningless “0xFF”(hexadecimal number). The stuffing byte field 49 and padding packet 42are provided for the same purpose of adjusting the pack length.Accordingly, conditions that the stuffing bytes are no greater than 7bytes and that the stuffing bytes 49 and the padding packet 42 cannot beprovided in the same pack are defined according to the DVD Videostandard. In the example illustrated in FIG. 4, since the padding packet42 is included in the video pack 40, the length of the stuffing bytefield 49 is zero bytes. That is to say, no stuffing byte fields areprovided.

The data structure of the video pack is shown in FIG. 4. Although notshown, the audio pack may have a similar data structure. Thus, the samestatement applies to the audio pack just by replacing the “videopackets” with an “audio packet” and the “video data” stored in thepayload with “audio data”. For example, in the VR-compliant stream 10 a,the PES extension field 48 is provided for the first audio pack in everyVOBU. In the Video-compliant stream 10 b on the other hand, the PESextension field 48 is provided for the first audio pack in only thefirst VOBU of each VOB.

EMBODIMENT 1

Hereinafter, the format conversion processing of the present inventionwill be outlined first, and then a first specific preferred embodimentof the present invention for realizing the format conversion will bedescribed.

FIG. 5 shows a correlation between the VR-compliant stream 10 a andVideo-compliant stream 10 b in format conversion processing according tothe present invention. The VR-compliant stream 10 a is obtained byencoding a content and is stored in a storage medium such as an opticaldisk 65 or a hard disk (not shown). For convenience sake, thecorrelation between the VR-compliant stream 10 a and Video-compliantstream 10 b is shown in FIG. 5 when one VOB of the VR-compliant stream10 a is converted into a VOB of the Video-compliant stream 10 b.

In converting the VR-compliant stream 10 a into the Video-compliantstream 10 b, it is necessary to perform the process steps of: (1)replacing the RDI packs 50, etc. with the navigation packs 51, etc; (2)nullifying the PES extension fields 48 included in the first video packs15 a, etc. and in the first audio packs 16 a, etc. of the second andfollowing VOBUs #2, #3 and so on and performing predetermined processingto adjust the pack length, thereby generating video packs 15 b and audiopacks 56; and (3) combining a VOBU #n with a video playback duration of0.4 second or less with the previous VOBU #(n−1) in the VR-compliantstream 10 a, thereby generating the VOBU #(n−1) for the Video-compliantstream 10 b.

As to the process step (1), in this preferred embodiment, theVR-compliant stream 10 a is encoded and the information to be describedin the resultant Video-compliant stream 10 b is stored in advance in theRDI packs 50 such that the format conversion can be carried outsmoothly. More specifically, the address information 33 a through 33 cof the video pack (see FIG. 3(c)) and the address information 34 of theaudio pack (see FIG. 3(d)) are stored in the manufacturer's informationfield 20 (see FIG. 2) of the RDI pack 50. Thereafter, during the formatconversion, those pieces of address information 33 a to 33 c and 34 aredescribed as they are in the general information 31 and sync information32 in the navigation pack 51. These pieces of information can bedescribed as they are because the arrangement order of the video andaudio packs as defined from the top of each VOBU remains the same inboth the VR-compliant stream 10 a and the Video-compliant stream 10 bbefore and after the conversion.

Next, in the process step (2), the PES extension fields 48 can benullified by deleting the PES extension fields 48. More specifically, aflag showing that there are no PES extension fields 48 is described inthe PES extension flag field 44 b (see FIG. 4). Then, by adding eitherthe padding packet 42 or the stuffing bytes 49, video packs 55 and audiopacks 56, each having a pack length of 2,048 bytes, are generated.Depending on whether or not the stuffing bytes are 7 bytes or less andwhether or not the stuffing bytes 49 and padding packet 42 are includedin the same pack, either the padding packet 42 or the stuffing bytes 49are added.

In each of the VR-compliant stream and Video-compliant stream, the PESextension fields 48 are included in the first video pack and the firstaudio pack in the first VOBU. That is why during the format conversion,no special processing such as the process step (2) needs to be carriedout on the first video pack 12 a and the first audio pack 13 a in VOBU#1 of the VR-compliant stream 10 a. Thus, the first video pack 52 andthe first audio pack 53 in VOBU #1 of the Video-compliant stream 10 bmay be the same as those packs.

Also, in this preferred embodiment, the process step (3) does not alwayshave to be carried out. This is because the VR-compliant stream isgenerated in this preferred embodiment such that each VOBU has a fixeddata size corresponding to a video playback duration of 0.4 second ormore as a matter of principle and there is no need to carry out theprocess step (3). In other words, the process step (3) needs to becarried out when a VR-compliant stream, in which the data size of VOBUsis not defined at all, should be converted.

Hereinafter, a data processor according to a first preferred embodimentof the present invention, which carries out these processing steps, willbe described with respect to its configuration and its more detailedprocessing.

FIG. 6 shows the arrangement of functional blocks in a data processor 60according to this preferred embodiment. The data processor 60 mayreceive a content such as an analog broadcast, generate a VR-compliantdata stream 10 a and then record the stream on a storage medium. Then,the data processor 60 can convert the stored VR-compliant data stream 10a into a Video-compliant data stream 10 b and output the Video-compliantstream 10 b. That is to say, the data processor 60 has a first functionof generating the VR-compliant stream 10 a from the content received, asecond function of recording the VR-compliant stream 10 a generated, anda third function of converting the VR-compliant stream 10 a into theVideo-compliant stream 10 b. The first and third functions may beimplemented by some hardware components provided on a dedicatedprocessing chip. Alternatively, those functions may also be realizedthrough a software program to be executed by a normal central processingunit (CPU).

Also, the present invention is described herein as being applied to astorage medium such as an optical disk like a DVD-RAM disk or a harddisk. However, the present invention is in no way limited to thosespecific preferred embodiments. Also, as long as the medium can store adata stream thereon, the optical disk may have a diameter of 12 cm or 8cm and may have any storage capacity.

The data processor 60 includes an encoder 61, a stream controller 62,and a hard disk drive (HDD) 63 and/or an optical disk drive 65, whichcan read and write a data stream from/on a hard disk (not shown) and/oran optical disk 64. The data processor 60 does not always have toinclude both of the HDD 63 and optical disk drive 65 but may include oneof them. Also, the data processor 60 may further include a semiconductorstorage medium and its reader/writer, for example, in addition to theoptical storage medium such as the optical disk 64 and the magneticrecording medium such as the hard disk. In the following description,however, the data processor 60 is supposed to include the optical diskdrive 65.

The encoder 61 receives a content, compresses and encodes the video andaudio information included in the content in compliance with the VRstandard to generate a VR-compliant stream 10 a, and then outputs thestream 10 a. Also, the encoder 61 describes address information,representing the addresses of the video and audio packs, as themanufacturer's information 20 in the RDI pack 50 in the VR-compliantstream 10 a.

The stream controller 62 receives the VR-compliant stream 10 a from theencoder 61 and outputs it to the optical disk drive 65. Also, the streamcontroller 62 receives the VR-compliant stream 10 a from either theencoder 61 or the optical disk drive 65, and extracts the addressinformation of the video and audio packs from the manufacturer'sinformation 20 defined in its RDI pack 50. Then, the stream controller62 generates a navigation pack 11 b compliant with the Video standard byusing that address information as it is, and replaces the RDI pack 50 ofthe VR-compliant stream 10 a with the navigation pack 11 b. Furthermore,the stream controller 62 locates the extension fields, which areincluded only in the first video pack and the first audio pack in thesecond and following VOBUs of the VR-compliant stream 10 a, and replacesthose fields with stuffing bytes or adds a padding packet 42 to the endof the packs. In this manner, the stream controller 62 obtains andoutputs a Video-compliant stream 10 b.

The optical disk drive 65 receives the VR-compliant stream 10 a from thestream controller 62 and stores the stream on the optical disk drive 65.Also, the optical disk drive 65 reads the VR-compliant stream 10 a fromthe optical disk 64 and outputs it to the stream controller 62.Furthermore, the optical disk drive 65 may also read and write theVideo-compliant stream 10 b obtained by the conversion.

Next, the detailed configurations and operations of the encoder 61 andstream controller 62 will be described.

The encoder 61 includes an elementary stream encoder 71, amanufacturer's information generator 72 and a system encoder 73. In thefollowing description, the elementary stream encoder 71 will be referredto herein as an “ES encoder 71” and the manufacturer's informationgenerator 72 will be referred to herein as an “MI generator 72”.

The ES encoder 71 receives a content from an analog broadcasting tuner.In response, the ES encoder 71 compresses and encodes the video andaudio information of the input content, generates video and audio packsand then outputs them to the system encoder 73. At the same time, the ESencoder 71 also outputs the address information of the video and audiopacks in which the video and audio data to be played back synchronouslywith each other are stored. The address information is obtained asinformation showing the pack number of a pack in question as countedfrom the top of a VOBU. More specifically, the address information(A_SYNCA) of an audio pack associated with certain video and theaddresses (VOBU_(—)1STREF_EA, VOBU_(—)2NDREF_EA, and VOBU_(—)3RDREF_EA)of the video packs including the last data of first, second and thirdvideo reference pictures are acquired. Then, the ES encoder 71 outputsthe address information acquired to the MI generator 72.

The MI generator 72 generates an RDI pack 50 compliant with the VRstandard. FIG. 7 shows a schematic data structure of the RDI pack 50.The MI generator 72 generates a pack header 75, a packet header 76 andso on, thereby making the RDI pack 50 compliant with the VR standard. Inthis case, the MI generator 72 describes the address information of thereceived video and audio packs as manufacturer's information data 77. Ascan be seen from FIG. 7, the data 77 includes the address information 34of the audio pack and the address information 33 a to 33 c of the videopack. FIG. 7 shows the data structure of the RDI pack 50 justschematically. That is why no system headers (see FIG. 2) are shown andthe packet header 76 is directly followed by the data 77. Actually,however, a system header may be included and any other data may beinserted between the packet header 76 and the data 77.

Next, the system encoder 73 will be described. The system encoder 73integrates together the video and audio packs output from the ES encoder71 and the RDI pack 50 output from the MI generator 72, therebygenerating a pack header and a packet header compliant with the VRstandard and inserting the RDI pack 50 into a data stream in which thevideo and audio packs are arranged.

Also, the system encoder 73 adjusts the video playback duration of aVOBU to a predetermined length of 0.4 second or more. Then, theconversion into the Video-compliant stream 10 b can be done with areduced processing load and with more ease. Optionally, the videoplayback duration of a VOBU may be less than 0.4 second. If such a VOBUis present, then that VOBU is combined with its previous VOBU to makesure that every video playback duration is 0.4 second or more before theconversion into the Video-compliant stream 10 b is done.

FIG. 8 shows the procedure of processing done by the encoder 61. First,in Step S81, the ES encoder 71 compresses and encodes the video andaudio information included in the content, thereby generating video andaudio packs. Meanwhile, in Step S82, the MI generator 72 acquires theaddress of the audio pack and the addresses of the video packs in whichthe first through third video reference pictures are stored from the ESencoder 71. Next, the MI generator 72 generates the manufacturer'sinformation data in Step S83 and the RDI pack 50 in Step S84,respectively. Finally, in Step S85, the system encoder 73 inserts theRDI pack into a data stream made up of a plurality of packs. In thismanner, the VR-compliant stream 10 a can be obtained.

Next, the stream controller 62 will be described with reference to FIG.6 again. The stream controller 62 includes a read/write processor 81, apadding packet detector 82, a decision element 83, a control and rewriteelement 84, a stuffing byte generator 85, a padding packet generator 86and a navigation pack generator 87.

The read/write processor 81 functions as a transmitter, which receivesthe VR-compliant stream 10 a and transmits the VR-compliant stream 10 ato the optical disk drive 65 in compliance with an interface standardwith the optical disk drive 65. In addition, the read/write processor 81also functions as a receiver for receiving the VR-compliant stream 10 athat has been read by the optical disk drive 65 from the optical disk64. Furthermore, the read/write processor 81 outputs the VR-compliantstream 10 a received to the padding packet detector 82 and the decisionelement 83.

For example, if the stream controller 62 and the optical disk drive 65are connected together through an ATA/ATAPI interface, then theread/write processor 81 is an ATA/ATAPI controller and transmits andreceives an ATA/ATAPI-compliant data stream to/from the optical diskdrive 65. However, this conversion processing does not constitute animportant feature of the present invention and the description thereofwill be omitted herein.

The padding packet detector 82 determines whether or not each pack ofthe VR-compliant stream 10 a has a padding packet, thereby outputtingdetection information, showing the presence or absence of the paddingpacket, to the decision element 83. This decision is made on each andevery pack. Thereafter, the padding packet detector 82 outputs theVR-compliant stream 10 a to the control and rewrite element 84.

Now it will be described how the padding packet detector 82 detects thepadding packet.

Specifically, the padding packet detector 82 detects the packet header41 a of each pack and acquires the packet length information that isstored in the packet length field 43 of the packet header 41 a. If thepadding packet detector 82 finds the packet length 2,028 bytes, then thedetector 82 judges that there are no padding packets. On the other hand,if the padding packet detector 82 finds the packet length less than2,028 bytes, then the detector 82 judges that there are padding packets.The reasons are that each pack has a fixed pack length of 2,048 bytes,that the pack header has a fixed length of 14 bytes, and the data lengthfrom the top of the packet header 41 a through the end of the packetlength field 43 is also fixed at 6 bytes. Also, since the padding packetshould be detected from the first video pack and the first audio pack inthe second and following VOBUs, there are no system headers. As aresult, the data length from the top of the pack through the end of thepacket length field 43 is 20 bytes. Accordingly, if the packet length isdescribed as 2,028 bytes, then it can be judged that only video andaudio packs are included in the pack and there are no padding packets.On the other hand, if the packet length is not equal to (i.e., lessthan) 2,028 bytes, then it can be judged that other data (i.e., apadding packet) should be included because that packet alone cannot meetthe prescribed pack length.

Next, in accordance with the detection information showing either thepresence or absence of the padding packet, the decision element 83determines what processing should be done to nullify the PES fields 48in the pack and outputs decision information. More particularly, inaccordance with the detection information, the decision element 83 makesthe following judgments (a) through (d) and outputs the decisioninformation, instructing what processing should be done, to the controland rewrite element 8.

(a) If there are no padding packets and if the stuffing byte length is 4bytes or less, then the PES extension fields 48 are replaced withstuffing bytes;

(b) If there are no padding packets and if the stuffing byte length isgreater than 4 bytes (i.e., 5 bytes or more), then the PES extensionfields 48 and the stuffing bytes are replaced with a padding packet;

(c) If there is a padding packet, then the PES extension fields 48 areintegrated into the padding packet; and

(d) If the pack currently processed is a pack of the first VOBU or apack including no PES extension fields 48, then the pack is used as itis.

In the processing steps (a), (b) and (c), it is determined which is moreappropriate to use either the stuffing bytes or the padding packet inorder to adjust the pack length by deleting the PES extension fields 48.In each of these situations, adjustments are made such that the stuffingbytes have a length of 7 bytes or less and that the stuffing bytes 49and the padding packet 42 are not included in the same pack.

In the processing step (d) on the other hand, there is no need tonullify the PES extension fields 48 and it is determined that the packis not processed. Optionally, on being notified by a host microcomputer(not shown), for example, that the pack currently processed is a one ofthe packs of the first VOBU, the control and rewrite element 84 may makethe decision (d) directly.

The contents of the processing steps (a) through (c) will be describedin further detail with reference to FIGS. 9(a) through 9(c).

The processing step (a) corresponds to the conversion shown in FIG.9(a). FIG. 9(a) shows how to perform a conversion process into stuffingbytes. The PES extension field 90 of 3 bytes is deleted and replacedwith a stuffing byte field 91 of 3 bytes.

In FIG. 9(a), there are no stuffing bytes in the pack yet to beconverted. However, stuffing bytes may also be included in advance aslong as their length is equal to or smaller than a reference length of 4bytes. The reason is that the PES extension field 48 has a field lengthof 3 bytes and the overall length will be 7 bytes or less if thestuffing bytes have a length of 4 bytes or less.

The decision element 83 calculates the data length of the existentstuffing bytes in the following manner. Specifically, the decisionelement 83 subtracts the field length of the PTS/DTS field 47 and thatof the PES extension field 48 from the data length described in theheader data length field 45 of the packet header 41 a.

In this case, each of the PTS and DTS fields 47 has a length of 5 bytesand its presence or absence is shown in the time flag field 44 a.Accordingly, the field length of the PTS/DTS field 47 is 0 bytes ifneither the PTS field 47 nor the DTS field 47 is present, 5 bytes ifeither the PTS field 47 or the DTS field 47 is present, and 10 bytes ifboth the PTS field 47 and the DTS field 47 are present. Also, the PESextension field 48 has a length of 3 bytes and its presence or absenceis shown in the PES extension flag field 44 b. Accordingly, the fieldlength of the PES extension field 48 is 3 bytes if there is a PESextension field 48 and 0 bytes if there is no PES extension field 48.

The decision element 83 can obtain the data length of the stuffing bytes49 by these calculations.

The processing step (b) corresponds to the conversion shown in FIG.9(b). FIG. 9(b) shows how to perform a conversion process into a paddingpacket. This processing step is adopted when the stuffing byte lengthwould exceed 7 bytes if the processing step (a) were performed. Thus, apadding packet, which makes a data length exceeding 7 bytes adjustable,is used. The PES extension field 92 a and stuffing byte field 92 b aredeleted from the packet header 94 and instead a padding packet 93 isadded. The packet length of the padding packet is equal to the sum ofthe field length of the PES extension field 48 and the data length ofthe stuffing bytes.

The processing step (c) corresponds to the conversion shown in FIG.9(c). FIG. 9(c) shows how to perform an integration process into apadding packet. This processing step is adopted when there is already apadding packet and no stuffing bytes can be added. The PES extensionfield 96 is deleted from the packet header 99 and padding bytes, havinga data length corresponding to the field length of the PES extensionfield 96, are integrated into the existent padding packet 98.

Referring back to FIG. 6, the control and rewrite element 84 receivesthe VR-compliant stream 10 a from the padding packet detector 82, thedecision information from the decision element 83, and the stuffingbytes from the stuffing byte generator 11 or the padding packet from thepadding packet generator 86, respectively. Also, the control and rewriteelement 84 performs the process of nullifying the PES extension fields48 in accordance with the decision information.

In this nullifying process, the control and rewrite element 84 changesthe flag in the PES extension flag field 44 b into a value showing thatthere are no PES extension fields 48 (e.g., “0”) and adds eitherstuffing bytes or padding packet.

If the decision information instructs to substitute stuffing bytes, thenthe control and rewrite element 84 replaces the data located in the PESextension fields 48 with the stuffing bytes supplied from the stuffingbyte generator 11.

On the other hand, if the decision information instructs that a paddingpacket should be substituted, then the control and rewrite element 84deletes the area for the PES extension field 48, shifts the followingpayload data thereto with no space left, and then adds a padding packetto the end of that packet. The packet length (PES_packet_length) of thepadding packet to be inserted is (3 bytes+stuffing byte length—packetheader length of 6 bytes of padding packet), i.e., (stuffing bytelength—3) bytes. During this processing step, the control and rewriteelement 84 rewrites not only the packet length field 43 and header datalength 45 in the pack but also the PES extension flag field 44 b aswell. The rewritten value of the PES extension flag field 44 b andrewritten header data length are obtained by subtracting 3 bytes,corresponding to the field length of the PES extension field 48, and thestuffing byte length from the original packet length and header datalength before the conversion.

It should be noted that if the decision information instructs that thepack be used as it is, then the control and rewrite element 84 does nothave to perform the process of nullifying the PES extension fields 48.The control and rewrite element 84 sequentially sends the processed ornon-processed packs to the navigation pack generator 87. Statedotherwise, the replacing and nullifying processing performed by thecontrol and rewrite element 84 is a pack conversion process. Also,supposing the converted pack remains the same as the pack yet to beconverted, the term “conversion” could apply even if no nullifyingprocess were carried out.

The stuffing byte generator 85 generates and outputs byte data having apredetermined value “0xFF” to be used as the stuffing bytes. Meanwhile,the padding packet generator 86 generates and outputs a padding packet42 having a predetermined packet header 42 a and padding data 42 b.Optionally, the packet length field and padding data 42 b may not befixed but may be described by the control and rewrite element 84 thathas fixed its packet length.

The navigation pack generator 87 extracts the address informationdescribed as the navigation information (i.e., A_SYNCA,VOBU_(—)1STREF_EA, VOBU_(—)2NDREF_EA, and VOBU_(—)3RDREF_EA) from themanufacturer's information 20 in the RDI pack 50 in the stream, therebygenerating a navigation pack 51 compliant with the Video standard. Itsdetailed data structure is just as described with reference to FIGS.3(a) through 3(d). Thereafter, the navigation pack generator 87 arrangesother rewritten or original packs (such as video and audio packs) andreplaces the RDI pack 50 with a navigation pack 51.

Next, if there is a VOBU having a video playback duration of 0.4 secondor less in the VR-compliant stream 10 a, then the navigation packgenerator 87 combines that VOBU with its previous VOBU into a singleVOBU. For example, if the VOBU #n shown in FIG. 5 is a VOBU having avideo playback duration of 0.4 second or less, then the navigation packgenerator 87 combines that VOBU #n with the previous VOBU #(n−1).Alternatively, the navigation pack generator 87 may extend the playbackduration of VOBU #n to more than 0.4 second by shifting the end timethereof.

The navigation pack generator 87 obtains the Video-compliant stream 10 bby performing this processing. Then, the navigation pack generator 87outputs the resultant Video-compliant stream 10 b.

Hereinafter, it will be described with reference to FIG. 10 how thestream controller 62 performs the format conversion processing. FIG. 10is a flowchart showing a procedure of the format conversion. First, inStep S100, the read/write processor 81 receives a VR-compliant stream 10a that has been read by the optical disk drive 65, replaces the RDI pack50 with a navigation pack 51, and extracts a video pack or an audio packfrom the VR-compliant stream 10 a. The padding packet detector. 82detects the packet length of the packets included in the pack in StepS101 and then determines in Step S102 whether or not the packet lengthis 2,028 bytes. If the answer is YES, then there are no padding packetsin the pack and the process advances to the next processing step S103.Otherwise, there is a padding packet and the process advances to theprocessing step S109.

The decision element 83 detects the data length of the stuffing bytes inStep S103 and then determines in Step S104 whether or not the datalength is 4 bytes or less. If the answer is YES, then the processadvances to the next processing step S105. Otherwise, the processadvances to the step S107. In Step S105, the decision element 83determines whether or not to nullify the PES extension fields 48. If theanswer is YES, the process advances to the next processing step S106.Otherwise, the process ends. The PES extension fields 48 should not benullified when the pack is included in the first VOBU of a VOB, forexample. In Step S106, the control and rewrite element 84 replaces thePES extension fields 48 with stuffing bytes. This processing stepcorresponds to the conversion shown in FIG. 9(a). That is to say, thecontrol and rewrite element 84 functions as a converting section forperforming conversion processing.

In Step S107, the decision element 83 also determines whether or not tonullify the PES extension fields 48. If the answer is YES, the processadvances to the next processing step S108. Otherwise, the process ends.In Step S108, the control and rewrite element 84 deletes the PESextension field 48 and the stuffing byte field and adds a paddingpacket. This processing step corresponds to the conversion shown in FIG.9(b). Next, the process advances to the processing step S111, in whichthe control and rewrite element 84 rewrites the packet length 43 and theheader data length 45.

On the other hand, in Step S109, the decision element 83 also determineswhether or not to nullify the PES extension fields 48. If the answer isYES, the process advances to the next processing step S110. Otherwise,the process ends. In Step S110, the control and rewrite element 84deletes the PES extension field 48 and adds a padding packet. Thisprocessing step corresponds to the conversion shown in FIG. 9(c). Next,in Step S111, the control and rewrite element 84 rewrites the packetlength 43 and the header data length 45.

By performing these processing steps on each and every pack, the datastream format can be converted from a VR-compliant one into aVideo-compliant one.

Next, another exemplary conversion processing will be described withreference to FIG. 11. FIG. 11 is a flowchart showing another procedureof the format conversion. First, in Step S120, either a video pack or anaudio pack is received as in Step S100 shown in FIG. 10. Next, in StepS121, the decision element 83 determines whether or not to nullify thePES extension fields 48. If the answer is YES, the process advances tothe next processing step S122. Otherwise, the process advances to theprocessing step S130. The padding packet detector 82 detects the packetlength of the packets in Step S122 and then determines in Step S123whether or not the packet length is 2,028 bytes. If the answer is YES,then there are no padding packets in the pack and the process advancesto the next processing step S124. Otherwise, there is a padding packetand the process advances to the processing step S128.

The decision element 83 detects the data length of the stuffing bytes inStep S124 and then determines in Step S125 whether or not the datalength is 4 bytes or less. If the answer is YES, then the processadvances to the next processing step S126. Otherwise, the processadvances to the step S127. In Step S126, the control and rewrite element84 replaces the PES extension field 48 with the stuffing bytes andfinishes processing that pack. In Step S127, the control and rewriteelement 84 deletes the PES extension field 48 and the stuffing bytefield and adds a padding packet. Thereafter, the process advances to theprocessing step S129.

In Step S128 on the other hand, the control and rewrite element 84deletes the PES extension field 48 and adds a padding packet. Next, inStep S129, the control and rewrite unit 84 rewrites the packet length 43and the header data length 45, thus finishing processing that pack.

According to the processing described above, a data stream compliantwith the DVD Video standard can be generated without decoding andre-encoding a data stream that was recorded so as to comply with the DVDVideo Recording standard. As a result, format conversion is realizedquickly without deteriorating the image quality. In addition, since theprocessing load is light, this method can also be implemented by even asystem with low processing performance.

On top of that, according to the processing described above, theplayback duration of a VOBU can also be adjusted during the formatconversion. Consequently, a VOBU compliant with the DVD Video Recordingstandard can have a more arbitrarily defined data size.

EMBODIMENT 2

In the first preferred embodiment of the present invention describedabove, the navigation information (i.e., the address information ofpredetermined video and audio packs) to be stored in a navigation packof a Video-compliant stream is supposed to be stored in advance in theRDI pack of a VR-compliant stream yet to be converted.

Meanwhile, in this second preferred embodiment, that navigationinformation is retained as a different file on a storage mediumseparately from the VR-compliant stream.

FIG. 12 shows the arrangement of functional blocks in a data processor160 according to this second preferred embodiment of the presentinvention. The data processor 160 includes an encoder 161, a streamcontroller 162, an HDD 163, an optical disk drive 165, and a hostmicrocomputer 166.

The data processor 160 is different from the data processor 60 of thefirst preferred embodiment in the respective operations of themanufacturer's information generator 172 in the encoder 161, the hostmicrocomputer 166, and the navigation pack generator 187 in the streamcontroller 162. Each of the other components shown in FIG. 12 performsthe same processing as its counterpart of the data processor 60identified by the same name in FIG. 6. Thus, the following descriptionwill be focused on operations involving those components that aredifferent from the counterparts of the data processor 60.

First, the MI generator 172 generates an RDI pack 11 a compliant withthe VR standard. In this preferred embodiment, however, the MI generator172 does not store navigation information in the manufacturer'sinformation field 20 of the RDI pack.

On the other hand, the host microcomputer 166 receives the addressinformation 33 a through 33 c and 34 of predetermined video and audiopacks shown in FIG. 7 (i.e., A SYNCA, VOBU_(—)1STREF_EA,VOBU_(—)2NDREF_EA, and VOBU_(—)3RDREF_EA) as navigation information fromthe ES encoder 171. Then, the host microcomputer 166 instructs theread/write processor 181 and optical disk drive 165 to store thenavigation information in a different data file separately from that ofthe VR-compliant stream.

It should be noted that to find what VR-compliant stream the navigationinformation stored in a navigation information file is associated with,a VR-compliant stream file and its associated navigation informationfile are preferably correlated with each other in one way or the other.For example, the VR-compliant stream file and navigation informationfile may be correlated with each other by giving them the same file nameand only different extensions. In that case, in converting the format ofa VR-compliant stream into that of a Video-compliant stream-after that,a navigation file associated with the given VR-compliant stream can belocated easily.

Furthermore, the host microcomputer 166 can get the stored VR-compliantstream file and navigation information file read by the read/writeprocessor 181. During the format conversion processing, the hostmicrocomputer 166 reads the navigation information file and outputs itto the navigation pack generator 187. Alternatively, the hostmicrocomputer 166 may generate the navigation pack 11 b by itself. As tothe format conversion processing, the pack may be converted in the sameprocedure as that described for the first preferred embodiment. Thus,the description thereof will be omitted herein for this preferredembodiment.

The navigation pack generator 187 stores the navigation information thathas been received from the host microcomputer 166, thereby generatingthe navigation pack 11 b. Then, the navigation pack generator 187detects the RDI pack 11 a from the VR-compliant stream and replaces theRDI pack 11 a with the navigation pack 11 b generated. It should benoted that these two replacing and replaced packs need to be packs forcontrolling the playback of associated video and audio packs such as theRDI pack 50 and navigation pack 51 shown in FIG. 5.

In each of the first and second specific preferred embodiments of thepresent invention described above, navigation information is supposed tobe generated when the VR-compliant stream 10 a is generated. However,the navigation information may also be generated while the VR-compliantstream 10 a is converted into a Video-compliant stream, not when theVR-compliant stream 10 a is generated.

Hereinafter, it will be described how to acquire the navigationinformation during the format conversion by using the data processor 60of the first preferred embodiment shown in FIG. 6.

On getting the VR-compliant stream 10 a read by the read/write processor81, the data processor 60 detects the various types of headers of theRDI pack 11 a, video pack and audio pack included in the VR-compliantstream 10 a and analyzes their contents. The headers to detect includeat least the sequence header, GOP header and picture header (none ofwhich is shown) in an elementary stream in the VR-compliant stream 10 a.These headers are well known in the art and detailed description thereofwill be omitted herein. As a result of the analysis, the data processor60 determines the arrangement of packs in the VR-compliant stream 10 aand acquires the address information of video packs, in which referencepictures required as the navigation information are stored, and theaddress information of an audio pack. In this manner, the navigationinformation to be stored in the navigation pack 11 b of theVideo-compliant stream 10 b can be obtained. The other processing stepsto be done for the purpose of format conversion are performed just asalready described for the first preferred embodiment.

In this manner, a content that was recorded so as to comply with the DVDVideo Recording standard can be converted into one compliant with theDVD Video standard quickly and without deteriorating the image quality.

In the foregoing description, format conversion from the VR-compliantstream 10 a into the Video-compliant stream 10 b has been described.However, the processing described above is also applicable to any datastream, other than the VR-compliant stream 10 a, as long as the datastructure of the alternative stream is similar to that of theVR-compliant stream 10 a. For example, the processing described above isapplicable to a movie take file (MTF) that defines a program streamcompliant with the MPEG2-Video standard. In an MTF, a P2 streamcorresponds to a VOB shown in FIG. 5 and a P2 sample corresponds to aVOBU. The P2 sample includes a control pack, which is used forcontrolling the playback of a data stream, at the top and a plurality ofvideo packs and audio packs that follow the control pack. Thus, the datastructure of the P2 sample is similar to that of the VR-compliant stream10 a described above.

When the present invention is applied to the P2 sample, the addresses ofrespective video and audio packs may be described in the control pack ofthe P2 sample.

In the first preferred embodiment described above, the addressinformation of reference picture related video packs and that of anaudio pack are described in the manufacturer's information field of theRDI pack. However, that address information may also be stored in anyother field. For example, a field for managing the overall data streamwith “stream information” may be provided and the address information ofthe reference pictures and that of an audio pack may be described inthat field. In the first preferred embodiment described above, threepieces of address information of the first through third referencepictures are supposed to be described in the RDI pack. Alternatively,the address information of only the first reference picture, forexample, may be stored in a different data file (control file) asdescribed for the second preferred embodiment. Furthermore, in thatcontrol file, a flag representing whether or not the address informationof the second and third reference pictures and the address informationof the audio pack are included in the stream information is preferablydescribed. For example, a flag of “1” may be set up when the addressinformation is described and a flag of “0” may be raised otherwise.

In the data processor 60 or 160 of the present invention, each of thefunctional blocks thereof may function either by itself or incombination with any other block. For example, if the data processor 60shown in FIG. 6 is a read-only DVD player, then the data processor 60consists of the optical disk drive 65 and the stream controller 62 only.When the optical disk 64, on which the VR-compliant stream 10 a of thepresent invention is stored, is loaded into the optical disk drive 65,the data processor 60 can perform the format conversion described above.

The data processor 60 or 160 can perform the processing of generating,writing and reading a data stream according to a computer program. Forexample, the processing of generating an encoded stream of a givencontent so that the stream can be easily subjected to format conversionmay be carried out by executing a computer program that is describedbased on the flowchart shown in FIG. 8. The format conversion processingitself may be carried out by executing a computer program that isdescribed based on the flowchart shown in FIG. 10 or 11. The computerprogram may be stored in any of various types of storage media. Examplesof preferred storage media include optical storage media such as opticaldisks, semiconductor storage media such as an SD memory card and anEEPROM, and magnetic recording media such as a flexible disk. Instead ofusing such a storage medium, the computer program may also be downloadedvia a telecommunications line (e.g., through the Internet, for example)and installed in the optical disc drive.

INDUSTRIAL APPLICABILITY

According to the present invention, a method and apparatus forconverting a data stream in a format, in which video information andaudio information are encoded, into a data stream in a different formatwithout re-encoding the former stream is provided. Since there is noneed to perform re-encoding, the processing can be speeded up and theprocessing load can be lightened. Thus, it is very easy to implementthis method even in an apparatus with low processing performance.

1. A method for converting a data stream in a first format into a datastream in a second format, wherein each said data stream includes datapacks in which video data and audio data are stored and a control packfor use in a playback control of the data stream, wherein in the datastream in the first format, address information, which representsaddresses of the data packs and which is not required while the datastream is played back, is present and associated with the data stream,and wherein in the data stream in the second format, addressinformation, which represents addresses of the data packs and which isrequired while the data stream is played back, is stored in the controlpack, the method comprising the steps of: acquiring the data stream inthe first format and the associated address information thereof;generating a second control pack in the second format from a firstcontrol pack in the first format, the second control pack storing theaddress information acquired; and replacing the first control pack withthe second control pack, thereby generating the data stream in thesecond format from the data stream in the first format.
 2. The formatconversion method of claim 1, wherein the data stream in the firstformat is an arrangement of multiple data units, each of the data unitsincluding a plurality of data packs and the first control pack, andwherein the method further comprises the steps of: locating an extensionfield, which is included only in a first one of the data packs, in eachof second and following data units; and replacing data of the locatedextension field with predetermined stuffing data.
 3. The formatconversion method of claim 2, further comprising the steps of: detectinga data length of a stuffing field, which is arranged after the extensionfield and in which the stuffing data is stored in advance; anddetermining whether or not the data length detected is a referencelength or less, wherein the step of replacing is carried out if the datalength is the reference length or less.
 4. The format conversion methodof claim 1, wherein the data stream in the first format is anarrangement of multiple data units, each of the data units including aplurality of data packs and the first control pack, each said data packincluding at least one packet in which either the video data or theaudio data is stored, and wherein the method further comprises the stepsof: locating an extension field, which is included only in a first oneof the data packs, in each of second and following data units; detectinga data length of a stuffing field, which is arranged after the extensionfield and in which stuffing data is stored in advance; determiningwhether or not the data length detected is a reference length or less;deleting the extension field and the stuffing field if the data lengthis greater than the reference length; and adding a padding packet, ofwhich a packet length corresponds to the combined field length of theextension and stuffing fields deleted, to the at least one packet. 5.The format conversion method of claim 1, wherein the data stream in thefirst format is an arrangement of multiple data units, each of the dataunits including a plurality of data packs and the first control pack,each said data pack including a packet in which either the video data orthe audio data is stored and a padding packet for adjusting a packlength of the data pack, wherein the method further comprises the stepsof: locating an extension field, which is included only in a first oneof the data packs, in each of second and following data units; deletingthe extension field; and adjusting a packet length of the padding packetaccording to a field length of the extension field deleted.
 6. Theformat conversion method of claim 1, wherein the address information isstored in the first control pack of the data stream in the first format,and wherein the step of acquiring the address information includesextracting the address information stored in the first control pack. 7.The format conversion method of claim 6, wherein the step of acquiringthe address information includes extracting the address informationstored in an attribute information field, on which an arbitrary type ofinformation is describable, within the first control pack.
 8. The formatconversion method of claim 1, wherein the step of acquiring the addressinformation includes extracting the address information stored in a datafile separately from the data stream.
 9. The format conversion method ofclaim 1, wherein the address information shows a storage location of adata pack in which a picture representing the video is stored and astorage location of another data pack in which audio to be reproducedsynchronously with the picture is stored.
 10. The format conversionmethod of claim 2, wherein the first one of the data packs correspondsto each of a first one of video packs including video data and that ofaudio packs including audio data.
 11. An apparatus for converting a datastream in a first format into a data stream in a second format, whereineach said data stream includes data packs in which video data and audiodata are stored and a control pack for use in a playback control of thedata stream, and wherein in the data stream in the first format, addressinformation, which represents the addresses of the data packs and whichis not required while the data stream is played back, is present andassociated with the data stream, and wherein in the data stream in thesecond format, address information, which represents the addresses ofthe data packs and which is required while the data stream is playedback, is stored in the control pack, the apparatus comprising: areceiving section for acquiring the data stream in the first format andthe associated address information thereof; and a pack generatingsection for generating a second control pack in the second format from afirst control pack in the first format, the second control pack storingthe address information acquired, the pack generating section replacingthe first control pack with the second control pack, thereby generatingthe data stream in the second format from the data stream in the firstformat.
 12. The format conversion apparatus of claim 11, wherein thedata stream in the first format is an arrangement of multiple dataunits, each of the data units including a plurality of data packs andthe first control pack, and wherein the apparatus further comprises: adecision section for locating an extension field, which is included onlyin a first one of the data packs, in each of the second and followingdata units; and a converting section for replacing data of the locatedextension field with predetermined stuffing data.
 13. The formatconversion apparatus of claim 12, wherein the decision section detects adata length of a stuffing field, which is arranged after the extensionfield and in which the stuffing data is stored in advance, anddetermines whether or not the data length detected is a reference lengthor less, and wherein if the data length is the reference length or less,the decision section instructs the converting section to make thereplacement.
 14. The format conversion apparatus of claim 11, whereinthe data stream in the first format is an arrangement of multiple dataunits, each of the data units including a plurality of data packs andthe first control pack, each said data pack including at least onepacket in which either the video data or the audio data is stored, andwherein the apparatus further comprises: a decision section for locatingan extension field, which is included only in a first one of the datapacks, in each of the second and following data units, detecting thedata length of a stuffing field, which is arranged after the extensionfield and in which stuffing data is stored in advance, and determiningwhether or not the data length detected is a reference length or less; apacket generating section for generating a padding packet; and aconverting section for deleting the extension field and the stuffingfield if the data length is greater than the reference length, adjustinga packet length of the padding packet according to the combined fieldlength of the extension and stuffing fields deleted, and then adding thepadding packet to the at least one packet.
 15. The format conversionapparatus of claim 11, wherein the data stream in the first format is anarrangement of multiple data units, each of the data units including aplurality of data packs and the first control pack, each said data packincluding a packet in which either the video data or the audio data isstored and a padding packet for adjusting a pack length of the datapack, wherein the apparatus further comprises: a decision section forlocating an extension field, which is included only in a first one ofthe data packs, in each of the second and following data units; and aconverting section for deleting the extension field and adjusting apacket length of the padding packet according to a field length of theextension field deleted.
 16. The format conversion apparatus of claim11, wherein the address information is stored in the first control packof the data stream in the first format, and wherein the pack generatingsection extracts the address information stored in the first controlpack.
 17. The format conversion apparatus of claim 16, wherein the packgenerating section extracts the address information stored in anattribute information field, on which an arbitrary type of informationis describable, within the first control pack.
 18. The format conversionapparatus of claim 11, wherein the pack generating section extracts theaddress information stored in a data file separately from the datastream.
 19. The format conversion apparatus of claim 11, wherein theaddress information shows a storage location of a data pack in which apicture representing the video is stored and a storage location ofanother data pack in which audio to be reproduced synchronously with thepicture is stored.
 20. The format conversion apparatus of claim 12,wherein the first one of the data packs corresponds to each of a firstone of video packs including video data and that of audio packsincluding audio data.
 21. A recording method to be used to record a datastream in a first format, comprising the steps of: receiving data of acontent representing video and audio; generating a data pack, in whichdata of the video is stored, and a data pack, in which data of the audiois stored, based on the data received; acquiring address informationthat represents the addresses of the data packs arranged; generating acontrol pack in accordance with control information, which is requiredfor controlling playback of the data packs; arranging the data packs andthe control pack in the first format, thereby generating the datastream; acquiring address information that shows a storage locations ofthe data packs in the data stream; and recording the address informationand the data stream on a storage medium in association with each other.22. The recording method of claim 21, further comprising the step ofstoring the address information in the control pack.
 23. The recordingmethod of claim 22, further comprising the step of storing the addressinformation in an attribute information field, on which an arbitrarytype of information is describable, within the first control pack. 24.The recording method of claim 21, further comprising the step of storingthe address information in a data file separately from the data stream.25. The recording method of claim 21, wherein the address informationshows a storage location of a data pack in which a picture representingthe video is stored and a storage location of another data pack in whichaudio to be reproduced synchronously with the picture is stored.
 26. Arecorder for recording a data stream in a first format on a storagemedium, comprising: an encoder, which receives data of a contentrepresenting video and audio, generates a data pack, in which data ofthe video is stored, and a data pack, in which data of the audio isstored, based on the data received and outputs address information thatrepresents the addresses of the data packs arranged; a generatingsection for generating a control pack in accordance with controlinformation, which is required for controlling playback of the datapacks; a system encoder for arranging the data packs and the controlpack in the first format, thereby generating the data stream; and awriting section for writing at least the data stream on a storagemedium.
 27. A recorder of claim 26, wherein the generating sectionacquire and describe the address information in the control pack.
 28. Arecorder of claim 26, wherein the writing section also store the addressinformation in a data file separately from the data stream.
 29. Acomputer program product of a data stream conversion program, theprogram being executable by a computer to be used to convert a datastream in a first format into a data stream in a second format, whereineach said data stream includes data packs in which video data and audiodata are stored and a control pack for use in a playback control of thedata stream, wherein in the data stream in the first format, addressinformation, which represents addresses of the data packs and which isnot required while the data stream is played back, is present andassociated with the data stream, and wherein in the data stream in thesecond format, address information, which represents addresses of thedata packs and which is required while the data stream is played back,is stored in the control pack, the program which when executed by thecomputer causes the computer to perform a processing, the processingcomprising the steps of: acquiring the data stream in the first formatand the associated address information thereof; generating a secondcontrol pack in the second format from a first control pack in the firstformat, the second control pack storing the address informationacquired; and replacing the first control pack with the second controlpack, thereby generating the data stream in the second format from thedata stream in the first format.
 30. A computer program product of arecording program, the program being executable by a computer to be usedto generate and record a data stream in a first format, the programwhich when executed by the computer causes the computer to perform aprocessing, the processing comprising the steps of: receiving data of acontent representing video and audio; generating a data pack, in whichdata of the video is stored, and a data pack, in which data of the audiois stored, based on the data received; acquiring address informationthat represents the addresses of the data packs arranged; generating acontrol pack in accordance with control information, which is requiredfor controlling playback of the data packs; arranging the data packs andthe control pack in the first format, thereby generating the datastream; acquiring address information that shows a storage locations ofthe data packs in the data stream; and recording the address informationand the data stream on a storage medium in association with each other.